Designers love their tools and processes. Many verbal battles have been fought about code or images, Photoshop or Sketch, paper or screen. And these discussions are serious. You’d think they were about whether to kill all kittens in the world.
“Why don’t you name your layers?”, asks Designer A, looking in disgust at her coworker’s latest instance of Artboard Copy 05. Designer B shrugs. Designer A visibly shakes, in the throes of obsessive compulsions.
Kittens are dying.
While I understand Designer A—after all, I wrote a book about a particular way of working—I often tend to side with Designer B. Here’s why.
Imagine two Sketch files. Both yield the exact same static image. In our example, stakeholders don’t see the Sketch file. Developers don’t see the Sketch file. They don’t see the layers; they don’t have to deal with the layers. In this case, it doesn’t matter how the layers are named.
Now imagine a relatively small design change. One designer makes a high fidelity mockup in Sketch with full spec. It takes an hour. Another designer opens the page in the browser, open the browser’s developer tools, makes some changes, and screenshots or saves the change and the dev tools CSS. It takes 10 minutes. Both communicate the same thing clearly, one takes less time.
Or a high-fidelity mockup where a super-quick Invision Freehand sketch and a couple of notes will suffice. Or a hand-drawn sketch on a sheet of paper and a 5-minute sit-down with a dev.
As designers, we’re good at asking critical questions. But often, we forget to do the same when it comes to our personal preferences regarding work tools and processes. Some of these questions will help provide direction about things such as naming conventions:
- How can I communicate this clearly, through the most effective application of my time and effort?
- Is this an artifact or a deliverable?
- Will others need to use it in non-exported form?
- Will this need to be reusable? To what degree?
The end result of a design effort, not including a product itself, is the communication of intent to those realising the production. Developers, for example. And usually non-technical stakeholders. This communication of intent, in whatever form, is your deliverable. All other side-effects leading to that deliverable are, arguably, artifacts. You could, in many cases, destroy them when you’re finished—without consequence.
How many of your Sketch files are really reused by other designers? How many are ever opened again? Do you work in a deeply data-informed environment, where myriads of A/B tests mean you’ll have to rework parts of a previous mockup that are irrelevant to your design changes? Is it quicker to take a screenshot of a current screen, and overlay changes? Are you putting effort into ways of working that make you feel good, but are irrelevant to communicating your intent?
It can be helpful for designers to ask themselves questions about the communication of intent. The following are in order. If you answer no to the first, then you ask yourself the next:
- Will a [quick] conversation suffice?
- Will a [quick] sketch suffice?
- Will a screenshot with annotations suffice?
- Will a low-fi mockup suffice?
- Will a hi-fi mockup suffice?
- Any combination of the above?
- I need a prototype. At what level of fidelity?
Of course, ideally you’d come up with questions that fit your own circumstances. These are just examples.
I get it. I do. Emacs vs vim. Gulp vs Grunt. React vs Vue. Sass vs LESS. Spaces vs tabs. (The answer is spaces.) Everybody has preferences, ways of working that are effective for them. But think critically about whether you’re solving the right problem. Those particularities of your own working style might not add much to your actual goal.
Sometimes we present ourselves with the illusion that we’re doing something important. But the biggest waste of time is doing that which need not be done at all.